The invention had its genesis in the banking failures of the 1980s which resulted in the merger of many financial institutions. As two institutions merged, there were substantial technical integration problems resulting from different equipment and different ADP philosophies. Retraining of users was required on the disparate systems of the merging organizations and there was a clash of corporate culture and doctrine which created a need for significant re-engineering of the business processes of the old organization(s), to the new.
Beyond the problems associated with merging organizations, there are also problems with modifying existing applications and adding new applications. The development process is too slow. The cross-discipline communication problems which exist between system developers and application end users are significant. It is therefore desirable to allow end users to add or modify processes with minimal or no involvement of ADP or systems personnel, and to do such work quickly.
Another problem which exists is that organizations seldom formally document the details of their business processes. This occurs in part because those processes change frequently and the people who know the processes are too busy performing the work to document the processes. Accordingly, it is desirable to have a mechanism for formally capturing and documenting business practices.
Reuse of software modules is also a difficult problem. Typically, these modules are created by programmers and other programmers either do not know of the work done by others or, if they have access to a library of such work, they are unable to recognize relevant modules using available indexing systems. Therefore, it is desirable to provide a mechanism for the reuse of modules in an easy and convenient manner.
FIG. 1 illustrates the problems of integrating two disparate automated data processing systems from two different banks. Bank 1 has an IBM host 101 running the MVS/XA operating system and running a DB-II database application. Bank 1 also has a second host 102 running the MVS/ESA operating system and a variety of older (legacy) banking applications. Bank 2 has a first host 111 running for example a Tandem.TM. operating system for general purpose processing and a second non-IBM host 112 running a non-IBM operating system and an SQL database management system.
Host 1 of Bank 1 has a network 103 running the SNA protocols at the higher levels and token ring at the lower levels. Each branch office has a multiplexer 107 which connects tellers 108 and ATM machines 109 to the network. Gateway 105 connects a second network 104 via gateway 106. Network 104 is a token ring network at the lower level protocol and SNA at the higher levels, with terminals 108 and 109 hanging off the network. Bank 2 has a network 113 using poll-select communications. Host 111 also services an X.25 network 114. Host number 2 of Bank 2 services a CSMA/CD network 116 utilizing TCP/IP protocols.
When integrating the automated data processing systems of the two banks together, one of the problems involves providing access to customer service representative 115 to all of the ADP resources at both banks. As illustrated in FIG. 1, this requires a network appearance on each of three networks 104, 113 and 116. Access by customer service representative to the fourth network, 103, occurs over gateway pairs 105, 106.
Customer service representatives (CSR) 115 may receive requests from the clients of either former bank and therefore must access systems from both banks. For example, if a customer calls in and requests account balance information, the customer service representative will need access to the host of the former bank on which that information resides. If a customer from the other former bank calls, the customer service representative would require access to the ADP resources of the other bank.
If a customer calls in with a request for a loan from the new merged bank, the request requires several transactions to satisfy such a compound or complex request. As shown in FIG. 2, first, the customer service representative would access a credit history (220) of the prospective borrower. Then, the CSR would access the account balance (230) and the credit card status (240) of the prospective borrower. Finally, the customer service representative might inquire as to the availability of bank funds (250) to fund the loan using yet another transaction.
The information required to satisfy the different kinds of information needed to satisfy a complex request might well be located on different hosts. Therefore, in the prior art, the customer service representative would be required to logon to the individual hosts, obtain the information and then manually arrange and assemble it in a manner that would permit a decision to be made on the loan request.
FIG. 3 illustrates a problem when large numbers of clients and hosts are involved. Assume that there were 10 hosts acting as servers for 1000 client work stations and that each client work station needed to access information rapidly from any of the hosts. Such an arrangement would require 10,000 sessions to be maintained over the network. Typically, this would strain the ability of the communication interfaces on the host to manage that number of sessions. Each host would be required to manage 1,000 sessions and each client would be required to manage 10 sessions as shown in FIG. 3. Therefore, it is desirable to reduce the number of sessions required to be maintained in order to service operations from a large number of clients.
In capturing information from a client for submission to a server, it is often desirable to replicate screens which the server produces. In the prior art, this is done by manually mapping out fields and screen literals on a blank format screen. This is cumbersome and often inaccurate. Accordingly, it would be desirable to have an ability to capture application screens from information provided from a back end host and utilize those screens either when capturing information from a front end client or when interacting with a back-end server.
When merging non-compatible ADP systems into a single environment, it is required to train operating personnel not only on the ADP equipment but on the business functions and procedures as well. It would desirable to minimize the training required by eliminating the need to train personnel on different types of ADP equipment.
Further, when modifying or instituting new business procedures, it would be desirable to be able to minimize or eliminate the involvement of programming personnel and have the change implemented by the business people only. From a users point of view, approaching the network as if it were a single entity even though it is composed in fact of heterogenous ADP systems would be very desirable. Isolating the end user from multiple protocols, multiple logons and session initiations, and hand shaking/security exchanges would also be desirable.